This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Awesome initiative! 👏
We have to see if creating functions on-demand works well in Hermes (React Native). If not, we can always do the generation as a build step, and ship the generated code in the package.
I'll take a closer look in the coming days 👀

If it can be autogenerated on build for everyone, that would be even better! Although downsides are code size, and not being able to use the library from node without compile step. (Node has experimental type stripping support)

To be able to validate if the generation works properly, I'd like to codegen to the file system, and commit. So even if a Node project would like to consume the library from source, it should work okay!

Oooh I see

Okay, I verified that the `new Function(...)` works fine on React Native 🎉. However, doing this at runtime still makes it impossible for things like Static Hermes or Porffor (JS compilers) to optimize them well AOT.

I would still attempt to offload this work AOT as a prepublish step, and ship the generated code. For now though, we can continue experimenting and pushing the performance with a JIT approach here, as it's easier to prototype with.

Alright, I think if we're able to support both the slow path (proxy) and the fast path (JIT functions), then we're going to have the best of both worlds. We can go back to generating these functions AOT if we find that that's the better approach.

@deluksic Would you be willing to update this PR with a check to see if new Function is supported? And if it's not, use the old Proxy approach? We can check it like so (credit to Brian Breiholz):

let EVAL_ALLOWED_IN_ENV: boolean;
try {
  new Function(`return true`);
  EVAL_ALLOWED_IN_ENV = true;
} catch {
  EVAL_ALLOWED_IN_ENV = false;
}

// ...

I'm looking at this and it is not super easy to switch this at runtime (not impossible). Are you sure we absolutely must support the proxy way? Do you know when new Function would not be supported where proxy and WebGPU are?

OK, I found this https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_eval_expressions

I will try to find a way to switch at runtime, hopefully by doing this check only once. It kinda defeats the purpose if every vec creation or access needs to check for new Function support.

I lied, I implemented the AOT version instead. It was actually easier. For now I created a scripts folder with the script that generates the getters which can be manually copied over to the abstract vector definitions (3 copy paste operations). In the future we can make it automatic, but honestly, this is one of those things you do once.

I have an idea for how to reduce the amount of code.

What if we add the 4-way swizzle directly on the VecBase? Sure, some of those getters would not be applicable for Vec2 and Vec3, but also users will never interact with these directly, so typescript would warn anyways. This way, only one manual copy is needed and we remove ~150 LOC.

Added it as an extra commit, we can revert if you don't like this approach.